11.4 Asynchrone Methodenaufrufe 

Wird aus einer Methode A heraus die Methode B aufgerufen, wird A erst dann mit den Operationen fortfahren, wenn B vollständig abgearbeitet ist. Die Ausführung der beiden Methoden erfolgt hintereinander, was als synchron bezeichnet wird. Synchrone Operationen haben einen gravierenden Nachteil, denn solange die Methode B ausgeführt wird, ist die Methode A blockiert. Um diese Problematik zu vermeiden, sollten beide Methoden asynchron, d. h., parallel nebeneinander operieren.

Asynchrone Bearbeitung setzt mindestens zwei Threads voraus. Sie haben auf den vergangenen Seiten die wichtigsten Techniken kennen gelernt, um mit Threads zu arbeiten. Sie wissen nun, wie Sie Threads erzeugen und diese möglicherweise synchronisieren können, damit Elemente nicht in einem ungültigen Zustand hinterlassen werden. Ihnen dürfte dabei nicht entgangen sein, dass die Technik sehr komplex ist und einer genauen Planung bedarf, um keine unbeabsichtigten und bösen Überraschungen zu erleben.

Sicherlich erinnern Sie sich noch an das Beispiel der Pumpeneinschaltung in Kapitel 7.5.1, als wir uns mit den Delegaten auseinander gesetzt haben. Die höchste Entwicklungsstufe hatten wir erreicht, als es uns gelungen war, den Client mittels Rückruf vom erfolgreichen Einschaltvorgang zu benachrichtigen (Beispiel SimpleDelegate). Die Lösung funktionierte tadellos, war aber – wenn man es ganz ehrlich und selbstkritisch beurteilt – unbefriedigend, denn sie setzte voraus, dass der Einschaltvorgang nur eine kurze Zeitspanne dauert. Das ist bei mechanischen Objekten sicherlich nicht gewährleistet. Um der Realität besser zu entsprechen, muss die Klassendefinition der Pumpe noch einmal überarbeitet werden,

Auch in der .NET-Klassenbibliothek finden sich sehr viele Klassen, die Dienste anbieten, deren Ausführung möglicherweise länger dauern kann. Die Dateioperationen zum Lesen und Schreiben zählen dazu. Betrachten wir dazu exemplarisch die Klasse FileStream, die das Schreiben in eine Datei bzw. das Lesen aus einer Datei ermöglicht. (Anmerkung: Wir werden uns den Klassen zur Ein- und Ausgabe in Kaptitel 12 zuwenden.) Neben den obligatorischen Methoden Read und Write, die beide synchron ausgeführt werden, werden von dieser Klasse in weiser Voraussicht des .NET-Entwicklerteams auch die asynchron operierenden Methoden BeginRead und BeginWrite veröffentlicht. Sehen wir uns kurz die Definition der erstgenannten Methode an, die aus einem Datenstrom in ein byte-Array einliest:

Der Rückgabewert des Methodenaufrufs ist ein Objekt, das die Schnittstelle IAsyncResult implementiert. Der Parameter vom Typ AsyncCallback ist ein Delegat, der eine Methode im Client beschreibt, die nach der Beendigung der Leseoperation aufgerufen wird.

Sowohl BeginRead als auch BeginWrite haben jeweils eine Partnermethode: EndRead und EndWrite:

Auch diese Methoden erwarten eine Referenz vom Typ IAsyncResult.

Zwei Dinge fallen sofort auf:

Wir wollen uns nun mit der Codierung einer asynchronen Ausführung beschäftigen. Danach wird auch die im ersten Moment sehr kompliziert erscheinende Parameterliste asynchron arbeitender Methoden (wie BeginRead) in einem anderen Licht erscheinen.

11.4.1 Asynchroner Methodenaufruf 

Der C#-Compiler stellt mit BeginInvoke und EndInvoke einem Delegaten zwei Methoden zur Verfügung, die im Rahmen einer asynchronen Operation von entscheidender Bedeutung sind.

Die Methode BeginInvoke ist sehr mächtig, denn mit ihrem Aufruf auf die Referenz eines Delegaten wird ein Hintergrundthread erzeugt, in dem die vom Delegaten beschriebene Methode ausgeführt wird. Der aufrufende Thread macht mit seiner eigenen Arbeit weiter, anstatt auf die Beendigung der aufgerufenen Methode zu warten.

Dazu ein kleines Beispiel. Nehmen wir an, dass die Methode AsyncTestProc, die eine längere Zeit zur Ausführung benötigt, aufgerufen werden soll. AsyncTestProc sei wie folgt definiert:

Ein Client, der diese Methode asynchron ausführen möchte, kann einen Delegaten deklarieren und diesem die Adresse der Methode AsyncTestProc übergeben:

Das reicht bereits aus, um AsyncTestProc in einem separaten Thread abzuarbeiten.

Dem Aufruf von BeginInvoke müssen Argumente übergeben werden, die unsere Anweisung noch nicht enthält. Sehen wir uns deshalb nun die Definition von BeginInvoke an.

Aufgerufen wird BeginInvoke auf die Instanz eines Delegaten, der auf eine bestimmte Methode zeigt. Weist die aufzurufende Methode eine Parameterliste auf, müssen die erforderlichen Argumente von BeginInvoke an die Methode weitergeleitet werden. Dazu dient die optionale Parameterliste.

Theoretisch wäre das bereits vollkommen ausreichend, um die aufgerufene Methode asynchron auszuführen. Meistens benötigt der Aufrufer aber Kenntnis von der Beendigung der asynchronen Ausführung, beispielsweise wenn er die Rückgabewerte verarbeitet. Folglich muss es eine Möglichkeit geben, die es der asynchron aufgerufenen Methode ermöglicht, den Aufrufer davon zu unterrichten, dass sie ihre Operationen beendet hat. Dabei kann es sich nur um den Aufruf einer Methode im Initiator der asynchronen Operation handeln.

Konsequenterweise muss der asynchron aufgerufenen Methode die Adresse der Rückrufmethode im Aufrufer bekannt ist. Das klingt wieder verdächtig nach einem Delegaten – und tatsächlich ist dem so, denn dem Aufruf von BeginInvoke werden nicht nur die Argumente übergeben, welche die asynchron aufgerufene Methode benötigt, sondern darüber hinaus auch ein Objekt vom Typ AsyncCallback, bei dem es sich um den erforderlichen Delegaten handelt.

Die Definition des Delegaten AsyncCallback lautet:

Die Methode, die aus der asynchron ausgeführten zurückgerufen wird, muss den Rückgabetyp void aufweisen und einen Parameter vom Typ IAsyncResult definieren.

BeginInvoke verfügt noch über einen weiteren Parameter vom Typ object. Hier kann beim Start der asynchronen Operation ein beliebiges Objekt übergeben werden, das Informationen beliebiger Art enthält.

Das hört sich komplizierter an, als es tatsächlich ist. Daher wollen wir den Ablauf schrittweise an einem kleinen Beispiel verfolgen. Gegeben seien dazu die beiden Klassen Program und ClassA wie folgt:

Aus Main heraus soll die Methode AsyncTest in der Klasse ClassA asynchron aufgerufen werden. Diese Forderung bewirkt, dass wir BeginInvoke auf einen Delegaten aufrufen müssen, der die asynchron auszuführende Methode im Objekt vom Typ ClassA beschreibt. Dazu wird zunächst auf Klassenebene der Klasse Program ein Delegat mit

deklariert. Anschließend verschaffen wir uns ein Objekt vom Typ des Delegaten, dem als Argument die asynchron auszuführende Methode übergeben wird.

Mit

wird die asynchrone Ausführung von AsyncTest in einem Hintergrundthread gestartet. Allerdings ist die Anweisung noch unvollständig – symbolisiert durch die Punkte. Wir sollten in Program nämlich noch eine Methode bereitstellen, über die der Hintergrundthread das Objekt vom Typ Program über das Ende seiner Operation benachrichtigt. Die Definition der Rückrufmethode muss der des Delegaten AsyncCallback entsprechen, demnach also einen Parameter vom Typ IAsyncResult enthalten. Wir nennen diese Methode MyCallBackProc.

Das Objekt vom Typ IAsyncResult entspricht dem Rückgabewert von BeginInvoke. Es veröffentlicht insgesamt sechs Eigenschaften. Dazu gehört unter anderem auch IsCompleted. Über IsCompleted kann der Aufrufer jederzeit feststellen, ob die asynchrone Ausführung bereits beendet ist. Eine zweite, sehr interessante Eigenschaft ist AsyncState, die genau das Objekt abruft, das als letzter Parameter dem Aufruf von BeginInvoke übergeben worden ist. Sie werden später in einem anderen Beispiel die sinnvolle Auswertung dieses Objekts sehen.

Wir wollen nun unser Beispiel komplettieren und sowohl innerhalb des Servers als auch innerhalb des Clients Code einsetzen, der tatsächlich einige Zeit in Anspruch nimmt, damit wir den Effekt des asynchronen Aufrufs tatsächlich beobachten können.

In der Abbildung 11.11 ist das Ergebnis des Aufrufs zu sehen. Es ist eindeutig zu erkennen, dass .P. bzw. .X. mehr oder weniger abwechselnd ausgegeben werden, denn beide Methoden arbeiten parallel. Beendet wird die asynchrone Operation durch den Rückruf von MyCallbackProc, was durch die Ausgabe des bekannten Satzes »Ich habe fertig« bestätigt wird.

Hier klicken, um das Bild zu vergrößern

Abbildung 11.11   Ausgabe eines asynchronen Aufrufs

Beispielprogramm – Pumpen asynchron einschalten

Das Beispielprogramm der Pumpenschaltung aus Kapitel 7 zeigte, wie die Pumpen mittels Rückruf den Client über das Einschalten der Motoren in Kenntnis setzten. In diesem Beispiel wurden die Pumpen der Reihe nach eingeschaltet. Dabei wurde jedoch nicht berücksichtigt, dass der Startvorgang durchaus eine gewisse Zeit in Anspruch nehmen kann. Jetzt soll das Programm so abgeändert werden, dass die Einschaltvorgänge nicht mehr hintereinander, sondern gleichzeitig erfolgen.

In diesem Beispielprogramm werden nicht die Delegaten auf die Startmethoden an die steuernde Klasse übergeben, sondern die Referenzen auf die Pumpen. Damit wir später die Pumpen identifizieren können, die sich bei der Rückrufmethode nach dem erfolgreichen Starten melden, ist die Pumpenklasse um einen Konstruktor und die Eigenschaft Bezeichner ergänzt worden. Die Eigenschaft liefert den Inhalt des Feldes bezeichner zurück.

Weil alle Pumpen dieselbe Methode im Client zurückrufen, bietet es sich an, der Steuerklasse den Delegaten auf diese Methode zu übergeben:

Die Referenz auf den übergebenen Delegaten hält das Objekt der Klasse ControlPumps in einer privaten Variablen vor.

Nachdem alle Pumpen in der Steuerklasse registriert sind, können sie durch den Aufruf von StartAllPumps im Client gestartet werden. In einer foreach-Schleife werden alle in der internen Auflistung gespeicherten Pumpenobjekte durchlaufen und für jedes Objekt ein Delegat erzeugt, der auf die objektspezifische Startmethode zeigt. Mit

wird anschließend BeginInvoke auf diesem Delegaten aufgerufen. Damit gewährleisten wir, dass die Startmethode der jeweiligen Pumpe in einem eigenen Thread ausgeführt wird. Das Besondere an diesem Aufruf ist, dass wir dem zweiten Parameter ein Zustandsobjekt übergeben – es handelt es dabei um die Zeichenfolge, die eine Pumpe eindeutig beschreibt.

In der Rückrufmethode des Clients kann das dem BeginInvoke-Aufruf übergebene Zustandsobjekt, das von der Steuerklasse an den Thread weitergereicht und von der Rückrufmethode übergeben wird, ausgewertet werden. Dazu dient die Eigenschaft AsyncState des IAsyncResult-Parameters. Damit wissen wir nicht nur, dass eine Pumpe angelaufen ist, sondern gleichzeitig auch, um welche es sich handelt.

11.4.2 Asynchroner Aufruf mit Rückgabewerten 

Möglicherweise liefert die asynchrone Methode als Resultat ihrer Operation einen Rückgabewert. Vielleicht werden auch über die Parameterliste Ergebnisse bereitgestellt. Wird aus dem Hintergrundthread heraus die Rückrufmethode des Initiators der asynchronen Operation aufgerufen, stehen die Ergebnisse jedoch nicht automatisch zur Verfügung, sie müssen ausdrücklich abgerufen werden. Dazu dient die Methode EndInvoke des Delegaten.

Wie bei BeginInvoke müssen Sie auch EndInvoke eine vorgeschriebenen Parameterliste übergeben, die nicht identisch mit der Parameterliste von BeginInvoke ist: Sie darf nur die Referenzparameter der asynchronen Methode enthalten, damit diese ihre Resultate dort hineinschreiben kann. Die Angabe der Werteparameter ist nicht erlaubt. Der einzige grundsätzlich immer zwingend erforderliche Parameter ist vom Typ IAsyncResult. Hier wird das Objekt übergeben, das die Rückrufmethode des Clients vom Server erhalten hat.

Wir wollen nun das Beispiel AsynchronerAufruf_1 ändern, um zu sehen, wie eine asynchrone Methode behandelt wird, die sowohl Werte- als auch Referenzparameter erwartet und darüber hinaus auch noch einen Rückgabewert hat. Dazu implementieren wir die Methode AsyncTest wie folgt:

Die Parameterliste enthält jetzt den Referenzparameter y und den Werteparameter x, außerdem liefert die Methode eine Zeichenfolge zurück.

Die Änderung der Signatur hat natürlich auch im auslösenden Thread Konsequenzen. Der Delegat, der den Aufruf der Methode kapselt, muss an die veränderten Bedingungen angepasst werden:

Gleiches gilt auch für den Start der asynchronen Bearbeitung, denn nun reicht es nicht mehr aus, mit BeginInvoke einfach nur einen Delegaten auf die Rückrufmethode zu übergeben sowie die Referenz auf ein Objekt, in das der asynchrone Aufruf Informationen schreiben könnte. Wir müssen stattdessen auch die Parameter der asynchronen Methode in der richtigen Reihenfolge bedienen:

AsyncTest nimmt nun eine Kopie des int-Wertes und die Adresse des long-Wertes entgegen, kann mit diesen die erforderlichen Operationen ausführen und zum Abschluss durch Aufruf der über callback bekannt gegebenen Adresse die Methode MyCallbackProc informieren.

Der Implementierung der Rückrufmethode kommt nun eine entscheidende Bedeutung zu. Es gilt, sowohl den Rückgabewert als auch den in diesem Fall geänderten Inhalt der Variablen lngVar auszuwerten. Dem Aufruf von EndInvoke übergeben wir die Adresse von lngVar und holen uns den Rückgabewert an der Konsole ab:

Die Konsolenausgabe bestätigt, dass unser Unterfangen von Erfolg beschieden ist: Wir erhalten sowohl die Zeichenfolge als auch den veränderten Inhalt des Feldes intVar.

Zum Abschluss fassen wir das Beispielprogramm noch einmal zusammen.

Interessant ist, innerhalb der Rückrufmethode ein wenig zu spielen. Wenn Sie beispielsweise der Meinung sind, Sie könnten auch mit

den Inhalt der als Referenz übergebenen Variablen lngVar auswerten, werden Sie Schiffbruch erleiden. Zu keinem Zeitpunkt schreibt die Methode des Hintergrundthreads den Inhalt 12345 in das Original. Ohne den Aufruf von EndInvoke bleibt das Original unbeeinflusst – es fehlt der äußere Anstoß, die neuen Daten zu übernehmen. Erst mit EndInvoke stehen diese zur Verfügung.

Wir könnten auch auf die Idee kommen, eine neue Variable vom Typ des Interface IAsyncResult zu deklarieren und diese an EndInvoke weiterreichen anstelle der im Parameter der Rückrufmethode entgegengenommenen:

Dieser Aufruf wird wirkungslos bleiben und zur Laufzeit im Nirwana enden. Denn was die Rückrufmethode MyCallbackProc im Parameter ar entgegennimmt, dient ihr gleichzeitig zum Aufruf eines ganz bestimmten Objekts des Servers – der IASyncResult-Parameter schafft die Möglichkeit der wechselseitigen Kommunikation. Wir haben es hier gewissermaßen mit einer Hintereinanderschaltung von Rückrufen zu tun.

11.4.3 Eine Klasse mit asynchronen Methodenaufrufen 

Am Anfang dieses Abschnitts wurde schon darauf hingewiesen, dass einige Klassen der .NET-Klassenbibliothek Methoden mit asynchroner Verarbeitung anbieten. Die Klasse FileStream im Namespace System.IO ist ein Beispiel dafür. Es werden allerdings nicht die Methoden BeginInvoke und EndInvoke aufgerufen, sondern zwei ähnlich lautende: BeginRead und EndRead bzw. BeginWrite und EndWrite.

Wir wollen uns nun ansehen, wie eine Klasse aufgebaut ist, die ähnlich wie FileStream implementiert ist. Dabei lernen wir einerseits, wie wir die asynchronen Methoden der Klassen des .NET Frameworks behandeln müssen, andererseits aber auch, diese Technik in eigenen Klassen zu nutzen.

Am Anfang steht die Idee, eine Methode zu entwickeln, von der wir annehmen, dass sie in Abhängigkeit von den Umgebungsbedingungen und der Art der Operation eine längere Zeit zur Bearbeitung in Anspruch nehmen kann. Wir wollen diese Methode nachfolgend Calculate nennen, die Klasse dazu Server.

Die for-Schleife simuliert eine länger andauernde Operation. Diese Implementierung arbeitet synchron. Da wir uns bewusst sind, dass Calculate vielleicht auch eine Stunde zur vollständigen Ausführung brauchen könnte (wir sind mit unserer Annahme sehr großzügig), bieten wir zusätzlich eine asynchrone Variante an. Dazu benötigen wir zwei weitere Methoden, die einer allgemeinen Konvention folgend als BeginXxx und EndXxx bezeichnet werden – in unserer Klasse demnach BeginCalculate und EndCalculate. Die noch unvollständige Klassenstruktur sieht dann folgendermaßen aus:

An dieser Stelle kommt es zu der wichtigsten Entscheidung überhaupt. Was wir beabsichtigen, ist die asynchrone Ausführung der Methode Calculate. Asynchronität heißt aber auch, dass ein weiterer Thread gestartet werden muss, sobald die Methode BeginCalculate aufgerufen wird. Wenn wir in dieser Methode ein Objekt vom Typ Thread erzeugen und seinem Konstruktor einen Delegaten übergeben, bräuchten wir auch noch ein Objekt, welches das Interface IAsyncResult implementiert, müssten zwangsläufig dessen Methoden implementieren usw.

Die Entwicklung auf diese Weise zu gestalten, ist sehr aufwändig. Es gibt eine viel einfachere Lösung, da die beiden Methoden BeginInvoke und EndInvoke genau das leisten, was wir brauchen. Also benutzen wir sie auch, um das Ziel effizient zu erreichen. Dazu wird die Logik, die in den Abschnitten 11.4.2 und 11.4.3 beschrieben wurde, innerhalb der Klasse Server implementiert.

Dem Aufruf der Methode BeginCalculate werden die Daten übergeben, welche die Methode Calculate für ihre Operation benötigt. In unserem Beispiel handelt es sich nur um einen als Werteparameter deklarierten Integer. Der zweite Parameter erhält die Referenz auf einen Delegaten, der die Rückrufmethode im Aufrufer beschreibt. Der dritte und letzte Parameter dient dazu, ein Objekt bereitzustellen, mit dem Daten zwischen dem aufrufenden und dem aufgerufenen Objekt ausgetauscht werden. Ein solches Objekt ist in unserem Beispielcode nicht vorgesehen.

Der Aufruf von BeginCalculate orientiert sich an dem von BeginInvoke – und das ist typisch für Klassen im .NET Framework, die asynchrone Methoden offen legen. Unter ähnlicher Prämisse wird auch EndCalculate implementiert, der Rückgabewert des internen EndInvoke-Aufrufs wird zum Rückgabewert der Instanzmethode.

Es bleibt zum Schluss noch zu testen, ob die Klassenimplementierung auch unseren Anforderungen genügt. Dazu entwickeln wir einen Client mit der Methode Start zum Aufruf der asynchronen Ausführung und einer Methode Results, die als Rückruffunktion vom Server angesteuert wird.

Die Ausgabe an der Konsole wird wie in der folgenden Abbildung gezeigt aussehen.

Hier klicken, um das Bild zu vergrößern

Abbildung 11.12   Ausgabe des Beispiels »AsynchronerAufruf_3«